OPTIMIZING CLIENT-SERVER COMMUNICATION FOR REMOTE SPATIAL DATABASE ACCESS

Technological advances in recent years have opened ways for easier creation of spatial data. Every day, vast amounts of data are collected by both governmental institutions (e.g., USGS, NASA) and commercial entities (e.g., IKONOS). This process is driven by increased popularity and affordability across the whole spectrum of collection methods, ranging from personal GPS units to satellite systems. Many collection methods such as satellite systems produce data in raster format. Often, such raster data is analyzed by the researchers directly, while at other times such data is used to produce the final dataset in vector format. With the rapidly increasing supply of data, more applications for this data are being developed that are of interest to a wider consumer base. The increasing popularity of spatial data viewers and query tools with end users introduces a requirement for methods to allow these basic users to access this data for viewing and querying instantly and without much effort. In our work, we focus on providing remote access to vector-based spatial data, rather than raster data. We explore new ways of allowing visualization of both spatial and non-spatial data stored in a central server database on a simple client connected to this server by possibly a slow and unreliable connection. We considered usage scenarios where transferring the whole database for processing on the client was not feasible. This is due to the large volume of data stored on the server as well as a lack of computing power on the client and a slow link between the two. We focus on finding an optimal way of distributing work between the server, clients, and possibly other entities introduced into the model for query evaluation and data management. We address issues of scalability for clients that have only limited access to system resources (e.g., a Java applet). Methods to allow these clients to provide an interactive user interface, even for databases of arbitrary size, are also examined

Effect of aliskiren on post-discharge outcomes among diabetic and non-diabetic patients hospitalized for heart failure: insights from the ASTRONAUT trial

Aims The objective of the Aliskiren Trial on Acute Heart Failure Outcomes (ASTRONAUT) was to determine whether aliskiren, a direct renin inhibitor, would improve post-discharge outcomes in patients with hospitalization for heart failure (HHF) with reduced ejection fraction. Pre-specified subgroup analyses suggested potential heterogeneity in post-discharge outcomes with aliskiren in patients with and without baseline diabetes mellitus (DM). Methods and results ASTRONAUT included 953 patients without DM (aliskiren 489; placebo 464) and 662 patients with DM (aliskiren 319; placebo 343) (as reported by study investigators). Study endpoints included the first occurrence of cardiovascular death or HHF within 6 and 12 months, all-cause death within 6 and 12 months, and change from baseline in N-terminal pro-B-type natriuretic peptide (NT-proBNP) at 1, 6, and 12 months. Data regarding risk of hyperkalaemia, renal impairment, and hypotension, and changes in additional serum biomarkers were collected. The effect of aliskiren on cardiovascular death or HHF within 6 months (primary endpoint) did not significantly differ by baseline DM status (P = 0.08 for interaction), but reached statistical significance at 12 months (non-DM: HR: 0.80, 95% CI: 0.64-0.99; DM: HR: 1.16, 95% CI: 0.91-1.47; P = 0.03 for interaction). Risk of 12-month all-cause death with aliskiren significantly differed by the presence of baseline DM (non-DM: HR: 0.69, 95% CI: 0.50-0.94; DM: HR: 1.64, 95% CI: 1.15-2.33; P < 0.01 for interaction). Among non-diabetics, aliskiren significantly reduced NT-proBNP through 6 months and plasma troponin I and aldosterone through 12 months, as compared to placebo. Among diabetic patients, aliskiren reduced plasma troponin I and aldosterone relative to placebo through 1 month only. There was a trend towards differing risk of post-baseline potassium ≥6 mmol/L with aliskiren by underlying DM status (non-DM: HR: 1.17, 95% CI: 0.71-1.93; DM: HR: 2.39, 95% CI: 1.30-4.42; P = 0.07 for interaction). Conclusion This pre-specified subgroup analysis from the ASTRONAUT trial generates the hypothesis that the addition of aliskiren to standard HHF therapy in non-diabetic patients is generally well-tolerated and improves post-discharge outcomes and biomarker profiles. In contrast, diabetic patients receiving aliskiren appear to have worse post-discharge outcomes. Future prospective investigations are needed to confirm potential benefits of renin inhibition in a large cohort of HHF patients without D

Accessing Diverse Geo-Referenced Data Sources with the SAND Spatial DBMS

The Internet has become the most frequently accessed medium for obtaining various types of data. In particular, government agencies, academic institutions, and private enterprises have published gigabytes of geo-referenced data on the Web. However, to obtain geo-referenced data from the Web successfully, systems must be designed to be capable of understanding the data sets published in different data formats. Also, even if the data sets are available in a simple known format, they often have poorly defined structures. With these issues in mind, we have developed an Internet-enabled data collection and conversion utility that interfaces with our prototype spatial database system, SAND. Using this utility, data can be retrieved from many different sources on the Web and converted into a format understandable by the SAND spatial database management system. Our collection and conversion utility is able to import the most popular data formats; namely, ESRI Shapefiles, Microsoft Excel files, HTML files, and GML files. Data in unstructured formats are verified for correct selection of the data types and handling of missing tuples before the insertion operation into the database. Moreover, our utility makes it possible to download any nonspatial data set and combine it internally with a relevant spatial data set. These features are accessible through a spreadsheet-like interface for online editing and structuring of data. 1

Accessing Diverse Geo-Referenced Data Sources with the SAND Spatial

The Internet has become the most frequently accessed medium for obtaining various types of data. In particular, government agencies, academic institutions, and private enterprises have published gigabytes of geo-referenced data on the Web. However, to obtain geo-referenced data from the Web successfully, systems must be designed to be capable of understanding the data sets published in different data formats. Also, even if the data sets are available in a simple known format, they often have poorly defined structures. With these issues in mind, we have developed an Internet-enabled data collection and conversion utility that interfaces with our prototype spatial database system, SAND. Using this utility, data can be retrieved from many different sources on the Web and converted into a format understandable by the SAND spatial database management system. Our collection and conversion utility is able to import the most popular data formats; namely, ESRI Shapefiles, Microsoft Excel files, HTML files, and GML files. Data in unstructured formats are verified for correct selection of the data types and handling of missing tuples before the insertion operation into the database. Moreover, our utility makes it possible to download any nonspatial data set and combine it internally with a relevant spatial data set. These features are accessible through a spreadsheet-like interface for online editing and structuring of data

Adding an Interoperable Server Interface to a Spatial Database: Implementation Experiences with OpenMap

Many organizations require geographic data originating from diverse sources in their dayto -day operations. It is often impractical to maintain on-site a complete database, due to issues of ownership, the sheer size of the data, or its dynamic nature. OpenMap TM is a distributed mapping system that allows displaying together geographic data acquired from disparate data sources. In this paper, we report our experiences with building a #specialist&quot; for OpenMap, allowing the OpenMap map browser access to data stored in SAND, a prototype spatial database system. DLG data from the U.S. Geological Survey was used to demonstrate the combined system. Key features of the OpenMap and SAND systems are described, as well as how they deal with the DLG data